In order to deploy seemingly dedicated resources to users of a shared computing environment, including but not limited to a cloud computing system, different solutions are introduced that create overlay networks on top of existing networks, by generating logical communication links between hosts within a service domain. One approach to implementing an overlay network includes tunneling, where a delivery network protocol encapsulates a payload protocol. However, various implementations of overlay network solutions are not always compatible with each other or able to communicate with each other. Two such approaches are Virtual Extensible Local Area Network (VXLAN) and Centralized NVO3 Implementation (CNI), as they differ in their implementations about the Control Planes (CPs), though they have the same frame encapsulation. Devices in one area of a computing environment utilizing VXLAN cannot communicate with devices in another area of a computing environment using CNI and vice versa because tunnel information from one solution cannot be introduced in the other.
VXLAN and CNI communicate in different ways in the CP. VXLAN has no dedicated CP and uses multicast tunnels for address resolution. CNI uses a centralized policy server, including a centralized controller and a centralized policy manager, to support tunnel resolution instead of the relying on a multicast query scheme, which is the core tunnel resolution mechanism of VXLAN. In CNI, tunnel endpoints are registered on the controller. Thus, a VM hosted in a VXLAN domain cannot communicate with a VM hosted in a CNI domain directly over an overlay network because of different address resolve mechanisms in the CP, even if both VMs use a VXLAN frame for tunneling.